Chapter 13. Security Requirements ‌

Overview
Each Matter security and privacy requirement references the underlying countermeasure (CM) and threat (T) in the Threat Model that motivated the need for the requirement. The requirements are grouped by topic. Unless stated otherwise, these requirements typically address all Devices and Nodes (i.e. all implementations of Matter functionality). Some requirements are called out specifically for a particular group of implementations, or Roles.
Device vs. Node
For some requirements, we need to differentiate between a Node (the entity which supports the Matter protocol stack) and a Device (a piece of equipment containing one or more Nodes).
- If the Node contains all of the Matter functionality, nevertheless it will probably rely on some security features of the Device.
- If the Node uses Matter functionality provided by the Device, the requirements obviously hold for both the Node and the Device.
Commissioning
1. Nodes SHALL stop both commissioning and unsecured rendezvous actions after a specified time period from the beginning of the commissioning mode when commissioning has not been concluded, unless allowed for other purposes such as Commissionable Node Discovery. The time period for commissioning and unsecured rendezvous announcements SHALL follow requirements as specified in Section 5.5, “Commissioning Flows” and Section 5.4.2.3, “Announcement Duration” respectively. [CM8 for T5, T7]
2. Nodes SHALL utilize multiple hash iterations in PBKDF, as required by definitions in Section 3.9, “Password-Based Key Derivation Function (PBKDF)”. Nodes SHALL validate the bounds of the iteration count for PBKDF, to respect the minimum and maximum values stated in the cryptography primitives section (see Section 3.9, “Password-Based Key Derivation Function (PBKDF)”). [CM99 in T102]
3. Nodes SHALL exit commissioning mode after 20 failed commission attempts (see Section 5.5, “Commissioning Flows”). [CM100 for T101, T112]
4. Devices SHALL include a Device Attestation Certificate and private key, unique to that Device. [CM23 for T22, T24, T34, T86]
5. When the setup code is not permanently attached to a device, for example, it is removable or only found in the device setup guide, the device SHALL NOT deliver the Onboarding Payload using an NFC tag [CM4 for T90].
6. If an NFC Tag is used to convey the Onboarding Payload from a device to a Commissioner, depending on how the NFC tag is associated with the device (e.g. device package, attached to the device, connected to the device…), the NFC Tag SHALL only allow the alteration of the Onboarding Payload and the reading thereof in ways and in device states attackers cannot
exploit to illicitly onboard the device (e.g., the alteration of the NFC Tag Onboarding Payload SHALL only be possible while being manufactured, the NFC tag read-out SHALL NOT be possible when the device is still in the packaging, the NFC Tag read-out SHALL only be allowed during the enabled commissioning window). [CM4 for T90]
Factory Reset
1. Devices and Nodes SHALL have a factory reset capability. [CM15 for T16, T17, T79, T82]
2. Factory reset SHALL remove from the Node all security- and privacy-related data and key material created during or after commissioning except data explicitly required to persist across resets. [CM35 for T16, T17, T79, T82]
See the following sections for detailed factory reset requirements.
- Section 6.4.3, “Node Operational Identifier Composition”
- Section 6.4.10, “Security Considerations”
- Section 6.6.3, “Access Control List Examples”
- Section 7.12.1, “Persistence”
- Section 7.14, “Event”
- Section 11.11, “General Diagnostics Cluster”
- Section 11.20.4.2, “Image Verification”
- Section 11.18.6.1, “NOCs Attribute”
- Section 11.18.6.2, “Fabrics Attribute”
- Section 11.18.6.4, “CommissionedFabrics Attribute”
- Section 11.18.6.5, “TrustedRootCertificates Attribute”
Firmware
1. Nodes SHALL support OTA firmware updates, either using Matter-provided means (see Section 11.20, “Over-the-Air (OTA) Software Update”) or proprietary means. [CM58 for T59]
2. Nodes SHALL validate the authenticity and integrity of the firmware prior to installation, such as through cryptographic means (see Section 11.20.4.2, “Image Verification”). [CM58 for T59]
3. Nodes SHOULD validate configuration and input for length, and acceptable values and ranges before applying them. This validation is dependent on the configuration or input being applied (see Access Control Cluster). Configuration and input validation is explicitly defined in relevant sections of the specification. [CM46 for T55]
Security Best Practices
This section describes best practices that Matter implementors SHOULD implement. Matter implementers SHALL indicate whether they comply or not to the best practices. Matter certification will not itself test that these requirements have been met.

NOTE
Policies and procedures for security best practices attestation have not been finalized.
Threats and Countermeasures

This section lists identified threats to Matter and countermeasures to mitigate those threats. This section is meant to be informational and not as normative requirements.

Table 133, “Threats” describes the threats, the agent involved in the threat as well as evaluates the consequences. This includes the severity, impact and likelihood of the threat being exploited.

Table 133. Threats

Threat Description			Threat Evaluation		Counterm easure
ID	Description	Threat Agent	Impact/Consequence	Severity	ID
T3	Reset Device and Commission for silent control (e.g. IP Camera to stream video).	Malicious house guest (brief physical access).	Silent control of Node and access to sensitive Node data (e.g. IP Camera traffic). If only 1 commissioning is allowed, user would detect issue later if/when they try to use Node.	High	CM4
T5	IoT device advertises information that can be used to identify vulnerabilities.	Malicious device or person with local network access.	Use information about the Device to exploit a (known) vulnerability.	High	CM6, CM7, CM8
T7	IoT device advertises information that can be used to identify, profile, or target a home or a user.	Malicious device or person with local network access.	Use information about available accessories to target a given home or user (e.g. to rob).	Medium	CM6, CM7, CM8
T9	Exploit vulnerability in the Device to gain arbitrary control over Device.	Any.	Unexpected control of Device to gain access to home data, instill fear, etc.	High	CM58, CM59

Threat Description			Threat Evaluation		Counterm easure
T15	Commission an uncommissioned Node without physical access to Device	Malicious neighbor or other nearby active attacker	Silent control of Node and access to sensitive Node data (e.g. IP Camera traffic).	High	CM3
T16	Seller of an Device (most likely a used one) intentionally leaves malicious software or configuration on the Device to compromise future traffic.	Malicious Device seller.	Control or access sensitive data of Device.	Medium	CM15, CM16, CM17, CM21, CM22, CM35
T17	Device buyer or trash picker dumps memory to find previous owner’s Device keys, group keys, and network credentials.	Malicious Device buyer or trash picker.	Access to sensitive data and ability to inject trusted data or even commands.	Medium	CM15, CM16, CM17, CM35
T20	Firmware (any software on Device that can be modified) is modified by attacker in factory (or remotely through factory)	Worker at factory or programming location or remote attacker	Local network behavior issues Infected Nodes leading to data breach, malfunction, denial of service, or attacks by this Node on other Nodes	Medium	CM21, CM22

Threat Description			Threat Evaluation		Counterm easure
T22	Cloned Device produced (with identical credentials to a proper Device).	Anyone with physical access to a Device from which they can extract Device Attestation credentials.	Brand damage if Device is of lower quality. Loss of revenue. Lack of function or interoperability if Device does not function properly. Lack of security if Device does not have proper security measures. Lack of support from manufacturer for cloned Devices.	Medium	CM23, CM77
T23	Counterfeit Device produced (with unique but apparently authorized credentials)	Worker at factory or programming location	Brand damage if Device is of lower quality. Loss of revenue. Lack of function or interoperability if Device does not function properly. Lack of security if Device does not have proper security measures. Lack of support from manufacturer for cloned Devices.	Medium	CM24
T24	Factory provisioned keys captured in factory, transit, or store (e.g., with fault injection or other tampering).	Worker in supply chain. Attacker who goes to retail store	Control of Device and access to sensitive Device data (e.g. IP Camera traffic).	Medium	CM23, CM113
T34	Cloned Device enters the network.	Manufacturer selling cloned Devices.	Loss of revenue or brand issues for original manufacturer.	Low	CM23, CM24

Threat Description			Threat Evaluation		Counterm easure
T39	Guessing security keys via brute force attack.	Attacker within radio range, captures encrypted network packets.	Control or access sensitive data of Device. Even control entire network if the private key for the Operational Certificate of a Controller can be guessed.	High	CM39
T52	Malicious Device off the network causes battery powered Device to wake too often.	Attacker using a Device on the network.	Shortened battery life of nearby Devices.	Medium	CM44, CM51
T53	Malicious Device off the network interrupts battery powered messages too often and greatly reduces battery life.	Attacker using a Device on the network.	Shortened battery life of nearby Devices.	Medium	CM44, CM51
T55	Device reconfigured improperly.	Attacker using a Device on the network.	Device could be configured such that it does not properly behave.	Medium	CM45, CM46, CM47
T59	Maliciously crafted message exploits Device vulnerability, causing Device compromise.	Attacker using a Device on the network.	Trusted Device could be hijacked.	High	CM57, CM58
T60	Physical tampering with Device permits compromise.	Attacker with physical access to Device.	Trusted Device could be hijacked.	Medium	CM62
T79	Device marked for destruction reused in network.	Installer or return agent.	Damaged or obsolete Devices may re-enter the network.	Low	CM15, CM16, CM20, CM35

Threat Description			Threat Evaluation		Counterm easure
T81	Attacker uses predictable Initialization Vectors to derive crypto keys.	Attacker able to observe network traffic from the Device.	Attacker discovery of Device crypto keys and other secrets, which can lead to control of other Devices if the Device has such privileges.	High	CM78
T82	Device buyer dumps memory to find previous owner’s user data.	Malicious Device buyer or dumpster diver.	User data may be leaked.	Medium	CM15, CM35
T84	Person with physical access to already installed Device resets. Device then scans QR code to gain access.	Attacker with physical access to Device.	Control of Device and access to sensitive Device data (e.g. IP Camera traffic).	Medium	CM4
T86	Leak certificate or Device identity private key to appear as valid Device.	Physical or locally compromised attacker.	Device appears as valid Device.	Low	CM23
T87	Malicious Device or party poses as valid Matter Node using operational credentials	Attacker on the local network or remotely controlling a Node on the local network	Group keys and sensitive data revealed to an invalid Node	Medium	CM87
T90	Long range camera captures QR code at Commissioning time or otherwise.	Malicious neighbor, robber, or other nearby active attacker.	Attacker manages to connect Device to their gateway or account.	Medium	CM3, CM89
T92	Microphone in the house can capture person speaking the setup code and use that to MITM Commissioning.	Malicious neighbor, robber, or other nearby active attacker	Attacker manages to connect the Node to their gateway or account	Medium	CM3

Threat Description			Threat Evaluation		Counterm easure
T94	Remote attack used to extract keys and other secrets.	Attacker able to access the Device remotely or over local network.	Attacker discovery of Device crypto keys and other secrets, which can lead to control of other Devices if the Device has such privileges.	High	CM107
T101	Malicious Device or person with local network access attempts to guess setup code via online brute force attack.	Attacker on the local network.	Control of Device and access to sensitive Device data (e.g. IP Camera traffic).	High	CM5, CM100
T102	Malicious Device or person with knowledge of passcode verifier uses offline brute force attack to derive setup code.	Attacker with remote access.	Control of Device and access to sensitive Device data (e.g. IP Camera traffic).	High	CM5, CM99
T110	Malicious device or party poses as valid Matter Administrative Node using operational credentials	Attacker on the local network or remotely controlling a Node on the local network	Control of Node and access to sensitive Node data (e.g., IP camera traffic)	High	CM87
T112	Malicious Device(s) or person(s) with local network access attempts to guess setup code of many Devices via online brute force attack.	Attackers on the local network.	Control of Device and access to sensitive Device data (e.g. IP Camera traffic).	Medium	CM5, CM100
T117	Incorrect fusing of production Devices.	Contract manufacturer, factory worker.	Device assets are vulnerable, security policies including secure boot might not be enforceable, etc.	High	CM113

Threat Description			Threat Evaluation		Counterm easure
T120	Data from Matter Nodes is shared with non-Matter or unauthorized entities (e.g. data leakage to adjacent non- Matter Nodes)	Any adversarial process running in the node that has enough privileges to modify ACLs. Secure boot is not sufficient protection if the device boots rarely and the malicious process was spawned post- boot up.	Matter data may be used in inappropriate or unauthorized ways potentially harming the owner.	High	CM87
T153	Commissioner/Ad ministrator adds untrustworthy Root CA to Node.	Malicious, compromised, or poorly advised Commissioner/Ad ministrator.	Attacker can create NOCs that enable impersonation and MITM of Secure Channels.	High	CM36
T168	DCL Private Key Exfiltration.	Attacker obtains one or more private keys of a company with DCL writer privilege.	Attacker can add to the block chain on behalf of the company. Can change the OtaUrl to point to old and known-vulnerable firmware or prevent an update from being installed.	High	CM163
T169	DoS/DDoS of Validators Nodes.	Attack can direct a DoS attack or resource exhaustion attack against validators. Attacker only needs to DoS 1/3+1 of validators to DoS consensus.	New blocks cannot be added.	High	CM163
T170	Unintended or premature exposure of information.	Company or certification lab posts device details to the chain and it is validated.	Immutability of block chain means the information is permanently on the chain.	High	CM160

Threat Description			Threat Evaluation		Counterm easure
T173	Malicious Device or person with local network access and knowledge of the passcode attempts to pair with a commissioned device when someone else opens the commissioning window using Section 5.6.2, “Basic Commissioning Method (BCM)” and the device’s Passcode.	Attacker on the local network	Control of Device and access to sensitive Device data (e.g. IP Camera traffic)	Medium	CM41, CM152, CM154
T174	Malicious Device gains knowledge of the Passcode on an uncommissioned Device, commissions the Device, and then puts it back into commissioning mode with the same Passcode using Section 5.6.2, “Basic Commissioning Method (BCM)” or Section 5.6.3, “Enhanced Commissioning Method (ECM)” to avoid detection.	Attacker on the local network	Control of Device and access to sensitive Device data (e.g. IP Camera traffic)	Medium	CM41, CM152

Threat Description			Threat Evaluation		Counterm easure
T175	Malicious Device with knowledge of the Passcode commissions an uncommissioned Device and then puts it back into commissioning mode with the same Passcode using Section 5.6.2, “Basic Commissioning Method (BCM)” or Section 5.6.3, “Enhanced Commissioning Method (ECM)” to avoid detection.	Attacker on the local network	Control of Device and access to sensitive Device data (e.g. IP Camera traffic)	Medium	CM41, CM152
T177	Attacker exploits a vulnerability that is common to most or all of the Validator Node software.	Attacker with some sort of DCL access (maybe just read, which is open to all).	Many Validator Nodes misbehave (e.g., approving adding or revoking a PAA or changing an OtaURL).	High	CM163
T180	Attacker accesses Observer Node or Validator Node with unauthenticated READ CLI protocol, mounts a DoS or DDoS attack.	Attacker that can send network messages to a DCL Observer Node or Validator Node.	DCL capacity diminished or eliminated. Unable to communicate important things like revocation of PAA.	High	CM163, CM166

Threat Description			Threat Evaluation		Counterm easure
T182	DoS/DDoS of Observers Nodes.	Attack can direct a DoS attack or resource exhaustion attack against Observer Nodes. If enough Observer Nodes are impacted by a DoS attack, the DCL may become unavailable.	DCL unavailable	High	CM166
T183	DoS on Trustees' approval process.	Submit many PROPOSE_ADD_AC COUNT requests. The Trustees can be overwhelmed with illegitimate requests. Requires compromise of a Trustee, although replay is possible.	Trustees overloaded	Medium	CM163
T185	DCL Denial of Service. Attacker writes a value to the ledger that is very large or out of bounds.	Authorized attacker sends a write request with very large parameter payload.	Very large ledger blocks added to ledger. This could cause validation problems. DOS on Observer Nodes if response is very large.	High	CM169
T186	Test House posts incorrect information about a vendor’s product.	Authorized test house.	False product info in ledger	High	CM163, CM167

Table 134, “Countermeasures” describes the various countermeasures to the threats listed in Table 133, “Threats”.

Table 134. Countermeasures

ID	Description
CM3	Commissioning is started with some form of physical user interaction (e.g. power cycle or button press).

ID	Description
CM4	For Devices subject to physical tampering (e.g. doorbell, camera, door lock, devices designed for outdoor use cases), the physical interaction to initiate commissioning and/or the setup code is not accessible to a physical attacker. E.g. setup Passcode is removable or not on the device, the button for the lock is inside the house.
CM5	All Devices include a randomly generated setup passcode and a corresponding passcode verifier derived from the setup passcode via a PBKDF. The setup code includes at least 27 bits of entropy compliant with a recognized standard (e.g., NIST SP 800-90B).
CM6	Unsecured rendezvous are enabled by a user action and, upon time-out or commissioning failure, will cause deletion of any state information. Examples of "user actions" are pressing a physical button, power-cycling a Device, and leveraging a previously commissioned account.
CM7	Minimize OS and other version information advertised during discovery.
CM8	Both commissioning and unsecured rendezvous actions time-out after at most 15 minutes from the beginning of the commissioning mode when commissioning has not been concluded.
CM15	Devices have a physical button or trigger for factory reset.
CM16	Devices rotate keys at specified triggers (e.g. Factory Device Reset).
CM17	Devices implement Perfect Forward secrecy key agreement protocols that give assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.
CM20	Revoke Device credentials and privileges when the Device is removed from the home.
CM21	Devices have cryptographically signed firmware, including all firmware and software on the Device.
CM22	Devices have a verified boot based in an immutable root of trust to verify the authenticity of firmware.
CM23	All Devices include a Device Attestation Certificate and private key, unique to that Device.
CM24	Manufacturers control the number of DACs issued under their Vendor ID.
CM35	Factory reset removes all local data and key material created during or after commissioning except data explicitly required to persist across resets.
CM36	A Commissioner / Administrator only adds Root Certificates that it trusts to a node.
CM39	Cryptographic keys are randomly chosen using the strong entropy separately required and the cryptographic algorithms and key lengths specified by Matter.
CM41	Administrators can view the set of Fabrics on each Device (i.e., Attributes for the Node Operational Credentials Cluster).

ID	Description
CM44	Administrator responds to reported or detected attacks and malfunctions (e.g., by adding Devices to a denylist, notifying the user, changing group keys, or hopping channels).
CM45	Configuration for secure channel protocol is carefully negotiated and validated by both parties.
CM46	Devices validate configuration and input changes for length, character type, and acceptable values and ranges before applying them. This validation is dependent on the configuration or input being applied (e.g. ACL entries). Configuration and input validation is explicitly defined in relevant sections of the specification.
CM47	Device management service uses a secure communication mechanism for reconfiguration.
CM51	Battery powered Devices respond to excessive queries by rate limiting (even limiting the rate to zero if desired).
CM57	Devices implement resiliency features (e.g., responding to secure boot failures with recovery or error signaling mode) to detect and handle compromise.
CM58	Devices support OTA firmware updates. Devices validate the authenticity and integrity of the firmware prior to installation.
CM59	Manufacturers monitor newly discovered vulnerabilities and provide software updates to address them.
CM62	Protection against physical attacks (especially those that impact cybersecurity) is needed for some Devices, as determined by the manufacturer.
CM77	All Devices protect the confidentiality of attestation (DAC) private keys. The level and nature of protection for these keys may vary depending on the nature of the Device.
CM78	Devices use random initialization vectors.
CM87	All Nodes protect the confidentiality of operational credential private keys. The level and nature of protection for these keys may vary depending on the nature of the Nodes.
CM89	The setup code is not photographable (e.g., NFC) or not visible when installed (e.g., QR code hidden with a flap).
CM99	Devices utilize multiple hashes in PBKDF.
CM100	Device exits commissioning mode after 20 failed commissioning attempts.
CM107	Devices include protection (if it exists) against known remote attacks that can be used to extract or infer cryptographic key material.
CM113	Fusing of Production Devices is done correctly. For example, disabling debug interfaces, and programming trust anchors for secure boot. There are multiple options to secure fusing on the factory floor (e.g., physically securing the fusing station, pre-fusing the silicon, etc).

ID	Description
CM152	Device manufacturers provide a way to secure a static Passcode after initial commissioning so that it is not available for unauthorized agents.
CM154	A device manufacturer implements Section 5.6.2, “Basic Commissioning Method (BCM)” only for devices that adequately secure the Passcode.
CM160	Vendors sign off on some other entity posting data about their products to the DCL.
CM163	Tightly restrict access to Validator Nodes (e.g., with VPN that only permits Validator Nodes, Observer Nodes, and authenticated clients with write access).
CM166	Matter vendors run and use their own Observer Node and restrict access to it to make sure that it stays available to that company’s DCL clients.
CM167	Matter vendors protect DCL private keys in HSM equipped servers.
CM169	All parameters passed in transactions and queries to the DCL pass input validation checks.

Chapter 13. Security Requirements ‌

Overview

Device vs. Node

Commissioning

Factory Reset

Firmware

Security Best Practices

NOTE

Cryptography

Commissioning

Firmware

Manufacturing

Resiliency

Battery Powered Devices

Tamper Resistance

Bridging

Distributed Compliance Ledger

Threats and Countermeasures